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AMENDMENTS TO THE SPECIFICATION : 

(1) Please amend the paragraph on page 1 , lines 6-1 1 , as follows: 

The invention relates to network selection procedures for communication 
networks, e.g. 4 JP- Internet Protocol (IP) networks such as wired and wireless local area 
networks (LANs). More specifically, the invention relates to arrangements wherein a 
plurality of network operators share an IP network. 

(2) Please amend the paragraph beginning on page 2, line 29, and ending on 
page 3, line 12, as follows: 

During authentication of clients requesting access to the network AN, the access 
service provider ASP will send an authentication request to one of the service providers 
directly connected thereto, namely VSP1 , VSP2, VSP3 or HSPC. In fact the access 
service provider ASP is not in a position to authenticate users A and B locally. In 
current arrangements, the access service provider ASP will take the corresponding 
decisions in an autonomous way, without receiving from the users A or B any input data 
other than their identity. Such a situation may explain why network advertising, i.e. 4 the 
announcement of network operators available in a given public WLAN and the need for 
network selection are described in documents such as 3GPP S2-031899 "WLAN 
Network selection", San Diego Meeting, 12-16 May 2003 

(www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_32_San_D io go/tdocs) , while indicating 
that the mechanism for network advertising is still "to be discussed". 
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(3) Please amend the paragraph on page 3, lines 13-21, as follows: 

An alternative arrangement based on XML meta-language has been proposed by 
document 3GPP S2-031864 "Network Selection", San Diego Meeting, 12-16 May 2003 
(www. 3gpp.org/ftp/tsg_Ga/WG2_Arch/TSGS2_32_San_Diogo/tdocs) . The 
corresponding arrangement has the disadvantage of requiring XML pre-configuration. 
Furthermore, the XML code has an increased amount of tagging information, which 
requires a greater amount of bits to be transmitted. 

(4) Please amend the paragraph beginning on page 3, line 30, and ending on 
page 4, line 4, as follows: 

The present invention also relates to a corresponding communication network 
and a computer program product loadable in the memory of at least one computer and 
including software code portions for performing the method of the invention. Reference 
to at least one computer is evidently intended to take into account that the method of 
the invention is adapted to be carried out in a docontra l isod decentralized manner, with 
different tasks being allotted to different computers in a network. 

(5) Please amend the paragraph on page 4, lines 15-20, as follows: 

This arrangement is independent from [[of]] the access technology deployed 
within the access network. This can be either wireless (e.g. 4 a WLAN network) or wired 
(e.g. 4 a PSTN network with dial-up access). For the sake of simplicity, a wireless LAN 
will be steadily referred to in the following as a preferred example. 
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(6) Please amend the paragraph beginning on page 4, line 28, and ending on 
page 5, line 8, as follows: 

A preferred embodiment of the arrangement described herein is based on the so- 
called Diameter agent supported in a Diameter base protocol. The basic related 
information is provided* e.g. 4 in IETF draft-ietf-aaa-diameter-17.txt 4 "Diameter Base 
ProtocorV - www.iotf.org . The Diameter agent is used to provide an authentication, 
authorization and accounting (AAA) framework for applications such as network access 
or IP mobility. Essentially, a Diameter agent is a Diameter node that provides either 
relay, proxy, redirect or translation services. Specifically, the arrangement described 
herein provides for certain modifications being made in the way specific Diameter 
requests are processed and the relative answers are created by the Diameter agent 
when these authentication requests have an unknown realm. 

(7) Please amend the paragraph on page 5, lines 17-25, as follows: 

Those of ordinary skill in the art will appreciate that the same arrangement could 
also be used with other "triple-A" protocols such as 4 e.g.* the protocol currently referred 
to as Remote Authentication Dial-In User Service (RADIUS): this does not provide for 
explicit support for agents, including so-called proxies, redirects and relays. The 
expected b e haviour behavior will not be defined, as this may vary for different 
implementations. 

(8) Please amend the paragraph on page 5, lines 26-35, as follows: 

The list of supported visited networks having a roaming agreement with a certain 
user's "home" ISPs are sent to the user by the authentication server of the provider 
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acting as the access provider. This preferably occurs during the user authentication 

procedure, using an extensible authentication protocol (EAP). This authentication 

protocol (as described, e.g.. in IETF draft-ietf-eap-rfc2284bis-03.txtrWAA^ 

supports multiple authentication mechanisms and typically runs directly over the link. 

(9) Please amend the paragraph on page 6, lines 1-7, as follows: 

For this purpose, a modification to the EAP procedure is advisable that consists 
in adding two messages to the normal sequence of packets exchanged during the 
authentication. However, the method proposed should be supported by a generic 
authentication mechanism i ndipondent l y independently of the underlying WLAN 
standard. 

(10) Please delete the paragraphs beginning on page 6, line 13, and ending on 
page 8, line 2, as follows: 

In a prosont l y proforrod ombodimont of th o i nvent i on, tho us e r i s i dent i f ie d 
un i voca ll y by moans of an id e ntifier. 

This may bo e .g. tho network access i dontif i or known as NAI doscr i bod o .g. in 
RFC 2486 3GPP S2 031864 "Network sel e ction", San D io go M oo t i ng, 12 16 May 2003 
(www.3gpp.org/ftp/tsg.sa/WG2.Arch/TSGS2_32_San_D io go/tdocs). 

I n such a proforr o d ombodimont, tho us o r sonds h i s or h o r crod o nt i als to th e 
access n e twork (wh i ch may occur by m o ans of ei ther a wirod d e v i co or a wirel e ss 
d o vico). Tho access network forwards thoso crodont i als to a back o nd auth e nt i cation 
sorvor, located at the data center of tho acc e ss s e rv i ce prov i der. Tho authonticat i on 
server r o triovos tho ava il ab le roaming networks for that usor, i dentifi e d through the 
-5- 
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roalm part of th o NA I . To accomp l ish th i s task, th o s e rver i n i tiates a conv o rsation w i th 

tho servers belonging to tho providers to which it i s connected. As a result, th e 

authenticat i on server retr i ev e s the l ist of operators that ho l d a roaming agr oo mont w i th 

tho user's oporator(s). This procodur o i s p e rformed on l y once when a f i rst 

authenticat i on roquost i s received by tho authent i cation s e rver i n resp e ct of a usor for 

wh i ch no direct roaming agreem e nts oxist with tho homo s e rver prov i der of such a user. 

Tho authent i cat i on server also forwards, via tho access n e twork, a list of operators to 

tho us o r. Tho user choos e s one of tho operators from th o l ist received from th o server, 

accord i ng to h i s or her prefer e nces, or based on som e pro configur e d settings. Wh e n 

present e d w i th such a l i st, tho user will send tho chosen operator identif i er back to the 

auth e nt i cation server i n th o access network and tho auth e ntication serv e r w i ll forward to 

tho prov i der choson by tho us o r tho authentication requ e st, conta i ning tho us e r's 

Of course, in th o case th e prov i d e r act i ng as tho acc e ss prov i der has a dir e ct 
roaming agr o omont with tho user's homo service provider, tho usor wi l l be pr e sented 
with a li st compr i s e d of one operator on l y. Alternative l y, und e r thos e c i rcumstanc e s, the 
authentication serv e r may simp l y d o cido to dir e ctly forward tho authent i cat i on roquost to 
tho user's hom o serv i ce prov i d e r. 

Tho usor wil l thon perform a usual authent i cation proc o duro w i th h i s service 
prov i d e r (for o xamplo, us i ng a standard mechan i sm l ike EAP). While p e rforming the 
stops of th i s procoduro, tho authenticat i on information flows through tho network of the 
previously choson operator. Specif i ca l ly, tho auth e nticat i on server wi ll forward 
auth e ntication messages to tho vis i ted authentication server. Those w i ll in turn proxy 
such m e ssag e s to th o hom o op e rator serv e r, i. o . th e hom o auth e nt i cat i on s e rver. 
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Boing g i v e n tho possib i lity of choosing the provider to which th o accoco sorvic o prov i der 

w i l l forward tho auth e ntication roquost, tho users w il l in fact rout o tho i r data flows w i th 

th o ensuing poss i b ili ty of mak i ng choicos e. g. in terms of pr i cing and qua li ty of s e rv i c e 

(QoS) grant e d. 

(11) Please amend the paragraph on page 8, lines 14-16, as follows: 

- figure 4 is a functional block diagram schematically representing a gon o ralisod 
generalized network selection procedure, 

(12) Please amend the paragraph on page 9, lines 7-9, as follows: 

It will be assumed that a 3G subscriber wishes to utilise utilize the resources and 
access to services within the respective own 3GPP operator network. 

(13) Please amend the paragraph on page 10, lines 7-15, as follows: 
The arrangement described is intended to give the user the possibility of 

selecting a s i gnalling signaling path to obtain authentication and authorization from the 
home network. Any subsequent user data flow will in fact be highly likely to follow the 
same path used for signalling signaling . The possibility thus exist for the user of making 
choices between different commercial agreement^ e.g. 4 in terms of pricing and quality 
of service (QoS) granted. 

(14) Please amend the paragraph on page 10, lines 22-35, as follows: 
This applies, e.g. 4 to the IEEE 802.1 1 standard, but similar remarks apply to 

other WLAN technologies. In fact, in the case of IEEE 802.1 1 WLANs, the WLAN 
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network name is conveyed over the WI_AN beacon signal in the so-called SSID (Service 

Set ID) information element. The possibility also exists for a user equipment (UE) to 

actively solicit support for specific SSIDs by sending a probe request message and by 

receiving a reply if the access point does support the solicited SS I Das SSIDs defined by 

IEEE 802.1 1 . However, in such prior art arrangements the user will not become aware 

of the set of supported visited networks and thus possb il y possibly select the path for 

reaching the desired home operator by using this mechanism. 

(15) Please amend the paragraph on page 1 1 , lines 9-24, as follows: 

In the case of WLAN-3G system interworking, support in that respect can be 
provided by a generic authentication mechanism (i ndipond e ntly independently of the 
underlying WLAN standard), such as^.g^the extensible authentication protocol 
currently referred to as EAP. In the case of 3G users the authentication mechanism to 
be transported may thus be basedi e.g.,, on the existing EAP/AKA authentication 
mechanism described in the Internet Draft "draft-arkko-pppext-eap-aka-09.txt", "EAP 
AKA Authentication", February 2003 ^wwwri otf.orq/ i ntorn o t drafts/draft arkko ppp ext- 
oap aka 09 . An alternative may be represented by the EAP/SIM authentication 
mechanism described in the Internet Draft "draft-haverinen-pppext-eap-sim-10.txt", 
"EAP SIM Authentication", February 2003 ^wwwHe tf.orq/ i ntornot drafts/draft hav o r i non 
ppp o xt eap s i m IQtxt . 

(16) Please insert the following paragraphs after page 12, line 8, as follows: 
In a presently preferred embodiment of the invention, the user is identified 

univocallv bv means of an identifier. 
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This may be. e.g.. the network access identifier known as NAI described, e.g., in 
RFC 2486 3GPP S2-031864 "Network selection". San Diego Meeting. 12-16 May 2003. 

In such a preferred embodiment, which is illustrated in Fig. 4. the user sends his 
or her credentials to the access network (which may occur bv means of either a wired 
device or a wireless device) via an AN (Fig. 4. Step 1 and Step 2). The access network 
forwards these credentials to a back-end authentication server, located at the data 
center of the access service provider. The authentication server retrieves the available 
roaming networks for that user, identified through the realm part of the NAI. To 
accomplish this task, the server initiates a conversation with the servers belonging to 
the providers to which it is connected (Fig. 4, Step 3). As a result, the authentication 
server retrieves the list of operators that hold a roaming agreement with the user's 
operator(s) (Fig. 4. Step 41 This procedure is performed only once when a first 
authentication reouest is received bv the authentication server in respect of a user for 
which no direct roaming agreements exist with the home server provider of such a user. 
The authentication server also forwards, via the access network, a list of operators to 
the user (Fig. 4. Step 5). The user chooses one of the operators from the list received 
from the server, according to his or her preferences, or based on some pre-configured 
settings. When presented with such a list, the user will send the chosen operator 
identifier back to the authentication server in the access network (Fig. 4. Step 6). The 
authentication server will forward to the provider chosen bv the user the authentication 
reouest. containing the user's credentials (Fig. 4. Step 7). 

Of course, in the case the provider acting as the access provider has a direct 
roaming agreement with the user's home service provider, the user will be presented 
with a list comprised of one operator only. Alternatively, under these circumstances, the 
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authentication server may simply decide to directly forward the authentication request to 

the user's home service provider. 

The user will then perform a usual authentication procedure with his service 

provider (for example, using a standard mechanism like EAPV While performing the 

steps of this procedure, the authentication information flows through the network of the 

previously chosen operator. Specifically, the authentication server will forward 

authentication messages to the visited authentication server. These will in turn proxy 

such messages to the home operator server, i.e.. the home authentication server (Fig. 

4. Step 8). Being given the possibility of choosing the provider to which the access 

service provider will forward the authentication request, the users will in fact route their 

data flows with the ensuing possibility of making choices, e.g., in terms of pricing and 

Quality of service (QoS) granted. 

(17) Please amend the paragraph on page 12, lines 11-15, as follows: 
As a first step, the access network device sends an EAP-request/identity 

message to the user equipment (UE) for user's credentials. EAP packets are 
transported over the wireless LAN interface encapsulated within any wireless LAN 
t o cnology technology specific protocol. 

(18) Please amend the paragraph on page 15, lines 16-22, as follows: 

As shown in figure 6, if the AauS receives all the redirect notifications with the 
redirect host AVP = unknown, then it forwards the authentication request, as received in 
the third step above, to the Vauo sp o d i f i od VauS specified in the default entry of its 
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routing table. This operation will be carried out only after the reception of the 

unsuccessful notifications. 

(19) Please amend the paragraph on page 18, line 20, as follows: 

The procedure for web-based user authentication, which is illustrated in Fig. 7, is 
described below. 

(20) Please amend the paragraph on page 18, lines 21-26, as follows: 

The User A requests a service from a wireless internet service provider ISP, e.g^ 
by "opening" a web browser and by subsequently requesting a URL (Fig. 7. Step 1) . 
The access network device intercepts the user's request and in turn asks the user for 
his or her credentials, via a HTML page (Fig. 7. Step 1) . 

(21) Please amend the paragraph beginning on page 18, line 27, and ending on 
page 19, line 3, as follows: 

The user A submits his or her identity (e.g. 4 in NAI format) and password. The 
credentials are transported to the access network device using HTTPS (Fig. 7. Step 2) . 
The access network device forwards them to the access authentication server (AauS) 
using Diameter encapsulation (Fig. 7. Step 2) . The access authentication server 
(AauS) in the WISP retrieves the available roaming networks for that user. These are 
identified through the realm part of the NAI identifier. To accomplish this task, the 
server initiates a conversation with all the servers belonging to the providers to which it 
is connected to, as described previously (Fig. 7. Step 3) . 
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(22) Please amend the paragraph on page 19, lines 4-7, as follows: 

As a result, the authentication server retrieves the list of operators that hold a 
roaming agreement with the user's operator (Fig. 7. Step 4) . The access authentication 
server (AauS) sends this list of operators to the user (Fig. 7. Step 5) . 

(23) Please amend the paragraph on page 19, lines 14-17, as follows: 

The list is presented to the user with a new HTML page with IP network selection 
links. The user chooses one of the operators included in the list received from the 
serve r, and the selection is then electronically sent back to the ASP via the AN (Fig. 7, 
Step 6) . 

(24) Please amend the paragraph on page 19, lines 18-25, as follows: 

At this point, the authentication server forwards the authentication request, 
containing the user credentials, to the provider chosen by the user (Fig. 7. Step 7) . The 
home authentication server accepts the user credential, checks the user's identity for 
validation and if authentication is successful, orders to the access authentication server 
to give the user service (Fig. 7, Step 8) . Tho corresponding procodur o i s dopict o d i n 
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